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Abstract 


The IETF has designed process changes over the last ten years in one 
of two ways: announcement by the IESG, sometimes based on informal 
agreements with limited community involvement and awareness, and 
formal use of the same mechanism used for protocol specification. 
The first mechanism has often proven to be too lightweight, the 
second too heavyweight. 


This document specifies a middle-ground approach to the system of 
making changes to IETF process, one that relies heavily on a "propose 
and carry out an experiment, evaluate the experiment, and then 
establish permanent procedures based on operational experience" model 
rather than those previously attempted. 
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1. Introduction 


This document specifies a middle-ground approach to the system of 
making changes to IETF process, one that relies heavily on a "propose 
and carry out an experiment, evaluate the experiment, and then 
establish permanent procedures based on operational experience" model 
rather than those previously attempted. 


2. Background and Specification 


Since the 1992 changes documented in [RFC1396], the IETF has used two 
mechanisms for process changes. 


1. IESG has adopted a number of procedural changes on its own 
initiative and documented them informally, utilizing the wide 
discretion implicitly granted to them by [RFC2026]. This provided 
a lightweight mechanism for change, but the lightness came with a 
cost: There was sometimes too little alignment with the larger 
IETF community. 


2. The IETF has also used the [RFC2026] protocol standards 
development process to identify a community of interest, hold one 
or more BoFs, charter a working group, discuss proposed changes 
within the community, develop IETF-wide consensus on the changes, 
and publish (usually) Best Current Practice specifications. This 
provided full community involvement but also came with a cost in 
flexibility. The IETF does not change its formal processes often 
(the IPR clarifications in [RFC3667, RFC3668] are the first 
documented changes to [RFC2026] since 1996), and the community is 
understandably reluctant to permanently alter or extend formally 
adopted processes with untried new procedures. 


There is a middle ground between BCP process updates and informal 
agreements. This document specifies regularizing and formalizing the 
informal IESG mechanisms listed in 1 above as a means of moving 
forward with procedural changes that might prove valuable. 


The mechanisms outlined here add to the IESG’s range of tools for 
dealing with process issues on an ongoing basis. They supplement the 
existing tools rather than attempting to replace them with a single 
"magic bullet". The choice of using the procedure outlined in this 
document or other mechanisms available to the IESG and the community 
—- present or future -- remains in the IESG’s hands. If the IESG 
does not exercise this discretion wisely, this document provides no 
additional remedies. 
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Some have interpreted the current procedures as giving the IESG all 
of the capabilities outlined here. If this were true, this document 
only encourages the IESG to use this type of mechanism more 
frequently in preference to less streamlined ones, and to more 
explicitly document its actions and decisions. 


This specification permits and encourages the IESG to adopt and 
institute "process experiments" by using the following procedure: 


1. An I-D is written describing the proposed new or altered 
procedure. A statement of the problem expected to be resolved is 
desirable but not required (the intent is to keep the firm 
requirements for such an experiment as lightweight as possible). 
Similarly, specific experimental or evaluative criteria, although 
highly desirable, are not required -- for some of the process 
changes we anticipate, having the IESG reach a conclusion at the 
end of the sunset period that the community generally believes 
things to be better (or worse) will be both adequate and 
sufficient. The I-D must state an explicit "sunset" timeout 
typically, not to exceed one year after adoption. 


2. If the IESG believes the proposal is plausible and plausibly 
useful, a four-week IETF Last Call is initiated. The IESG can 
institute whatever procedures it wishes to make this determination 
and to avoid denial of service attacks from large numbers of 
spurious or unimportant proposals. In particular, they might 
institute a procedure requiring a number of endorsements, or 
endorsements of a particular type, before the IESG considers the 
proposal. The IESG is, however, expected to understand that 
procedures or review processes that act as a mechanism for 
significant delays do not fall within the intent of this 
specification. 


3. At the conclusion of the Last Call, the IESG reevaluates the 
plausibility and appropriateness of the proposal. If they 
conclude that the proposed experiment is appropriate, a second I-D 
is generated (either by the IESG or by the original authors with 
IESG advice) that cleans up any definitional issues exposed in the 
Last Call and that explicitly identifies and responds to issues 
raised during the Last Call. 


4. The document and experiment are then announced, the experiment is 


begun, and the document is forwarded for publication as an 
Experimental RFC. 
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The IESG is explicitly authorized to use this mechanism (based on 
Experimental RFCs) to gain experience with proposed changes to BCP 
specifications. There is no requirement to approve a BCP 
specification for the experiment until the experiment is found to 
have value. 


The IESG could, of course, reach a "bad idea" conclusion at any stage 
in this process and abandon the experiment. It might recommend 
publication of the experimental document, with a discussion of why it 
was a bad idea, but is not required to do so. The list above is 
deliberately vague about where the I-Ds come from: a WG, design team, 
individual contribution, editing group, or other mechanism could be 
used in the first and/or third steps, but no specific mechanisms are 
required, and the IESG is explicitly permitted to generate such 
proposals internally. 


In each case, the IESG’s decision to go forward (or not) with a 
procedural experiment, or the steps leading up to one, is expected to 
reflect their judgment of the existence of rough consensus in the 
community. That judgment may be appealed using the usual procedures, 
but the IESG and the community are reminded that an experimental 
attempt to try something for a fixed period is typically a better 
engineering approach than extended philosophical discussion without 
any experience to back it up. 


Nothing above is to be construed as requiring an IETF-wide attempt 
for any given process experiment. A proposal for such an experiment 
may specify selected areas, selected working groups, working groups 
meeting some specific criteria (e.g., those created after a 
particular time or of a specified age), or be specific in other ways. 


At or before the end of the "sunset" timeout, the IESG would either 
revise (or cause to be revised) the document into a BCP RFC or the 
procedure would expire and, presumably, not be tried again unless 
something changed radically. A document describing why the 
experiment had succeeded or failed would be desirable but could not, 
realistically, be a requirement. If the procedure went to BCP, the 
BCP would reflect what we would call "operational experience" in the 
real world. 


We note that, if the procedures the IESG has adopted (and the 
procedural exceptions it has made) over the last decade are 
legitimate, then the IESG has the authority to institute the changes 
specified here by bootstrapping this process. 
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Security Considerations 


This document specifies a mechanism for evolving IETF procedures. It 
does not raise or consider any protocol-specific security issues. In 
considering experimental changes to procedures, the IESG should, of 
course, exercise due caution that such changes not reduce the quality 
of security review and consideration for protocols or, at least, that 
the process experiment proposals contain early detection and 
correction mechanisms should quality deterioration occur. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2004). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and at www.rfc-editor.org, and except as set 
forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the ISOC’s procedures with respect to rights in ISOC Documents can 
be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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